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ABSTRACT 

This paper provides an historical and empirical 
critique of the claim that learning to program Will promote the 
develppment of general higher mental functions. A developmental 
perspective on learning to program is provided which incorporates 
cognitive science studies of mental activities involved in 
progratmBing, ind highlights the importance of prdgramming contexts, 
instructional contexts, and a student's relevant background knowledge 
and reasoning skills for the task of learning to pio^ram. The 
following topics are discussed: claims for cognitive effects of 
learning to program; the devillopmetttal role of contexts in learning 
to progr^; the programming environment; the instructional 
environment; what constitutes skilled programming; levels of 
programming skill development; cognitive constraints on learning to 
program; and evidence for cognitive effects of programming. Types of 
transfer outcomes expected from each of the different levels of 
programming skill development are described, and a concluding 
statement and a 14-page list of references are included. 
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Revolutionary changes are taking place in education* in content as 
well as method. Widespread computer access by schools is at the 
heart of these changes. Throughout the. world, but particularly in 
the United States, educators are usiiig computers for learning activi- 
ties aciross the curriculum and are even designing their own software. 
But virtually all educators are as anxious and uncertain about these 
changes and the directions to take as they are optinilStic about their 
ultimate effects. They ask: "Now that this admittedly powerful 
symbolic device is in our schools, what should we do with it?" 

We believe that educators and social scientists are at a critical water- 
shed in American education. Important new opportunities abound for 
research and development work that can influence directly the quality 
of education. Hard questions are emerging about the design of 
educational activities that integrate the computer with other media. 
The volatile atmosphere of choices for schools (and parents) , as new 
hardware and software appear daily, calls for principles and knowl- 
edge educators can use, derived from systematic empirical studies in 
laboratories and classrooms, of how children learn with these new 
information technologies . We also need theoretical debates on the aims 
and priorities for education in an information age. We believe that a 
developmental approach to the understanding of information technolo- 
gies will be required that incorporates the new insights of cognitive 
science and will guide both research on and design of computer-based 
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learning environments. This developmental cognitive science disci- 
pline wotild merge theory and practice to dovetail the symbolic powers 
of human thinking with those of the computer in the service of human 
development. 

As described in this essay, our goals are considerably more modest 
but, nonetheless, a timely subtask of the larger enterprise. Our aim 
is to examine two widespread beliefs about the mental activities en- 
gaged by. programming a computer and their expected cognitive and 
educational benefits. The two beliefs are polar oppcsites and neither 
is acceptable. Together, they express the predominant tendencies in 
thinking about learning to program today. 

The first belief is linked to an atomistic, behavioriist tradition that 
views learning narrowly. This is the traditional and deeply engrained 
idea that learning is simply an accumulation of relatively autonomous 
facts. In this view, what die learns when learning to program is the 
vocabulary of commands (primi' .ves) and syntactic rules for con-^ 
structing acceptable arrangements of commands. This belief underlies 
most programming instruction. Its other facet is that what one learns 
when learning programming is just a programming language. 

The contrasting belief, in part a reaction to the first belief, is that 
through learning to program, children are learning much more than 
programming "facts." It is being daimedi that children will acquire 
higher cognitive skills such as planning abilities, problem-solving 
heuristics, and reflectiveness on the revisionary character of the 
problem-solving process itself. This belief, although new in its 
application to this domain, is an old idea in a new costume. It is 
based on a common, albeit extreme, assumption about learning — that 
spontaneous experience with a powerful symbolic system will have 
beneficial cognitive consequences, especially for higher order cogni- 
tive skills. Similar arguments have been offered in centuries past for 
mathematics, logic, writing systems, and Latin (see Bruner, 1966; 
Cole & Griffin, 1980; Goody, 1977; Olson, 1976; Ong, 1982; Vygot- 
sky, 1978). 

The intuitively plausible claims for the cognitive benefits of pro- 
gramming have broadened in scope and in public attention. Al- 
though, as yet, there is no evidence to support these claims, their 
presumed validity is affecting important decisions in public education 
and leading to high expectations for outcomes of programming in the 
school and home. In the current climate of uncritical optimism about 
the potential cognitive benefits of learning to program, we run the 
risk of having the naive "technororoantic" ideas become entrenched in 
the school curriculum by affirmation rather than by empirical verifi- 
cation through a cyclic process of research and development. At the 



pre-high school level, programming is being taught primarily because 
of its assumed impact on higher cognitive skills, not because profi- 
ciency in programming is itself an educational goal. This assumption 
takes on added significance since several million precoUege-age chil- 
dren in the United States are already receiving instruction in com- 
puter programming each year, and France has recently made program- 
ming compulsory in their precoUege curriculum, on a par with mathe- 
matics and native language studies. 

With the rapid rise in the teaching of programming , it has become 
critical for decision makers in education to understand how program- 
ming is learned, what the cognitive outcomes may be of learning to 
program, what levels of programming skill may be required to obtain 
different types of outcomes, and what the relationships are between 
the cognitive constraints on learning to program and its cognitive 
consequences. Research directly addressing these questions is in 
its infsuicy. 

Throughout our paper, we will highlight major issues and fundamental 
complexities for researchers in designing studies responsive to these 
critical questions. We discuss these issues in terms of a hybrid 
developmental framework that incorporates cognitive science and 
developmental psychology, and review relevant research in cognitive 
science and its cognate disciplines. This synthesis recognizes the 
inadequacies of either an extreme knowledge-building account of 
learning to program, or the naive technoromariticisin that postulates 
spontaneous higher order cognitive skills as outcomes of programming 
experiences. Although claims about the spontaneous cognitive impact 
of programming have an intuitive appeal, we show them to be miti- 
gated by consideration of factors involved in learning and develop- 
ment. We also demonstrate how, in practice, the fact-learning ap- 
proach to programming often leads to incomplete programming skills. 
Cognitive studies of what expert programmers know, the level of the 
student's programming skills, the goals and purposes of those learn- 
ing to program, and the general difficulty of transferring powerful 
ideas across domains of knowledge all contribute to our rejection of 
these two views. Programming, in the classroom may fundamentally 
alter the ways in which learning and cognitive development proceed. 
But we must examine whether such bold claims find, or are likely to 
find, empirical support. 

Throughout our analysis of these issues, we have felt that a develop- 
mental perspective that incorporates the seminal work in the last 
decade of the interdisciplinary field of cognitive science will illuminate 
our understanding of the potentialities of information technologies for 
advancing human cognition. Fundamental contributions to thinking 
about and concretely establishing the educational roles of information 



technologies could be gained from the synthesis of these two impor- 
tant theoretical traditions. 

Developmental theorists such as Piaget and Inhelder (1969), Werner 
(1957), an^ Vygotsky (1978) have provided accounts of developmental 
processes with profound implications for the role of technologies in 
education. In all these views, cognitive development consists not of 
an accumulation of facts, but of a series of progressive reorganiza- 
tions of knowledge driven by the child's active engagement with 
physical and social environments. In these views, learning (i.e., the 
accumulation of new knowledge) is important for driving the develop- 
mental process but, at the same time, is mediated by the current 
developmental capabilities of the learner. 

During the last decade, researchers in the constituent disciplines of 
cognitive science— cognitive psychology, computer science, linguistics, 
anthropology, and philosophy— have begun intensive collaborative 
research projects (e.g.. Centner fr Stevens, 1983 j Greeno, Glaser & 
Newell, 1983 r Norman, 1981). The combination of careful analysis of 
cognitive processes and the techniques of computer simulation has led 
to important new insights into the nature of mental representations, 
problem-solving processes, self-knowledge, and cognitive change. 
Cognitive science has revealed the enormous importance of extensive, 
highly structured domain-specific knowledge and the difficulty of 
developing general-purpose, problem-solving strategies that crosscut 
different knowledge domains. In addition, within particular domains, 
cognitive science research has been able to specify in great detail the 
naive "mental models'* held by novices, such as Aristotelian beliefs 
about objects in motion, which are often very resistant to change 
through spontaneous world experience (Centner & Stevens, 1983). 

Cognitive science shares with the older tradition of developmental 
psychology a concern with how new learning must be integrated with 
prior knowledge, but it transcends earlier work in analyzing problem 
solving and learning processes for specific knowledge domains, and 
finds little role for general structural principles invoking "stages." 

For a student interacting with a programming environment, for ex- 
ample, a developmental perspective would indicate the importance of 
studying how these students' current knowledge of the computer 
aystem is organized, how they regulate and monitor their interactions 
with it, and how their knowledge and executive routines affect the 
ease or pace of acquisition of abilities to use new programming con- 
structs. It would also investigate the students' exploration of the 
system, and the ways in which they are able to assimilate it into their 
current level of understanding and to appropriate it in terms of their 
own purposes, including play and competition. Learning to use the 



programming language may require successive developmental reorgani- 
zations not only of the students' naive understanding of the language 
being learned, but of the computer system as a whole. Complex 
cognitive changes are unlikely to occur through either spontaneous 
exploration or explicit instruction abne, since students must be 
engaged in the task in order to interpret the new concepts. This 
perspective suggests that, rather than engaging in the current 
argument over global questions such as which computer language is 
best for children, we would do better to ask how we can organize 
learning experiences so that in the course of learning to program, 
students are confronted with new ideas and have opportunities to 
build them into their own understanding of the computer system and 
computational concepts. ; 

In complementary terms,, cognitive science raises such important 
questions as: How can common systematic misconceptions in particular 
domains of knowledge be diagnosed and remediated through either 
informal or formal learning activities? For example, what does a 
student specifically need to know in order to comprehend and use 
expert strategies in designing a computer program? What component 
mental processes are engaged in programming activities? 

The synthesis of developmental cognitive science focuses on diagnos- 
ing the mental models and mental processes that children as well as 
adult novices bring to understanding computer programming, since 
these models and processes serve as the basis for understanding 
transformations of their systems of knowledge as they learn. Beyond 
the typically agenetic cognitive science, a developnietttal cognitive 
science wcild askt How are the various component mental processes 
involved L\ expert programming constructed and reconfigured 
throughout ontogenesis, and accessed and organized during problem- 
solving episodes? Through what processes of reorganization does an 
existing system of thought become more highly developed? Through 
what learning activities in what kinds of environments does the novice 
programmer develop into an expert? Developmental cognitive science 
asks how the mind ani its ways of knowing are shaped, not only by 
biological constraints or physical objects, but by the available cultural 
interpretive systems of social and educational interaction. As we 
shall see, the currently available research is impoverished in response 
to these questions, but current progress in understanding the devel- 
opment of mathematical and scientific thinking (reviewed, for example, 
in Siegler, 1983) leads us to be optimistic about the prospects for 
comparable work on the psychology of programming. 

The critique of the literature on learning to program that we present 
below has been strongly influenced by this developmental cognitive 
science perspective. Wc do not adopt the usual computer program- 
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ming perspective which assumes that all programming students are 
adults or have the same goals as mature learners • Instead , our 
perspective is geared to the learning experiences and developmental 
transformations of the child or novice adult in interactive environ-* 
ments. The kinds of preliminary questions we ask from this perspec- 
tive in addressing the question — What are the cognitive effects of 
learning to program — lead us to draw on studies from diverse fields 
that we see as relevant to a developmental cognitive science of pro- 
gramming. We have categorized them according to the following 
topics: What are the developmental roles of contexts in learning to 
prorg^ram? What is skilled programming? What are the levels of pro- 
graming skill development? What are the cognitive constraints on 
learning to program? Firsts however, we will begin by examining the. 
bold claims about the effects of learning to program. 

Claims for Cognitive Effects of Learning to Program 

Current claims for the effects on thinking of learning to program are 
best exemplified in the writings of Papert and Feurzeig on the Logo 
programming language (e.g., Feurzeig* Horwitz Er Nickerson, 1981; 
Feurzeig 9 Papert, Bloom » Grant & Solomon, 1969} Goldstein & Papert, 
1977J Papert; 1972a, 1972b, 1980} Papert, Wattr DiSessa & Weir, 
1979), although such claims are not unique to Logo (s^e Minsky, 
1970). 

Early claims . Two key catalysts underlie beliefs that programming 
will discipline thinking • The first is from artificial intelligence, 
where constructing programs that model the complexities of human 
cognition is viewed as a way of understanding that behavior. It is 
contended that you learn more about your own thinking when you 
teach the computer to do something. Papert (1972a) draws the anal- 
ogy that, because of the necessarily explicit nature of programming, 
students will learn about problem*^8olving processes as they articulate 
the assumptions and specify the steps of their problem-'solving ap- 
proach* 'phe second influence is the widespread assimilation of con- 
structivist epistemologies of learning, most familiar through Piaget^s 
work. Papert (1972a, 1980) has been an outspoken advocate of the 
Piagetian account of knowledge acquisition through self-guided prob- 
lem-solving experiences, and has extensively influenced conceptions of 
the benefits of learning programming through '^a process that takes 
place without deliberate or organized teaching^ (1980, p. 8). 

Ross and Howe (1981) have summarized Feurzeig et al.'s (1969) four 
claims for the expected cognitive benefits of learning programming. 
Initially, most outcomes were postulated for the development of mathe - 
matical thought: 



(1) that programming provides some justification for, and 
illustration of, formal mathematical rigour; (2) that pro- 
gramming encourages children to study mathematics through 
exploratory activity. (3) that programming gives key in- 
sight into certain mathematical concepts; and (4) that 
programming provides a context for problem solving, and a 
language with which the pupil may describe his own problem 
solving, (p. 143) 

Papert (1972b) argued for claims (2) through (4), noting that writing 
programs of Logo turtle geometry is a 

new piece of mathematics with the property that it allows 
clear discussion and simple models of heuristics (such as 
debugging] that are foggy and confusing for beginners 
when presented in the context of more traditional elemen- 
tary mathematics [our emphasis]. 

He provides anecdotes of children "spontaneously discovering" phe- 
nomena such as the effects that varying numerical inputs to a pro- 
/c^dwre' for drawhig a spiral have on the spiral's shape. He concludes 
that learning to make these "small discoveries" puts the child "closer 
to mathematics" than faultlessly learning new math concepts. 

Recent claims . We find expanded claims for the cognitive benefits of 
programming in a new generation of theoretical writings. In Mind - 
storms , Papert (1980) discusses the pedagogy surrounding Logo, and 
argues that cognitive benefits will emerge from taking "powerful 
ideas" inherent in programming (such as recursion and variables) in 
"mind-size bites" (e.g., procedures). One of his more dramatic 
claims is that if children had the extensively different experiences in 
thin!(4ng about mathematics that Logo allows, he sees "no reason to 
doubt that this difference couM account for a gap of five years or 
more between the ages at which conservation of number and combina- 
torial abilities are acquired" (p. 175). Here, Papert is referring to 
extensively replicated findings of a large age gap between the early 
conservation of number (near age 7) and later combinatorial abilities 
(e.g., constructing all possible pairings of a set of different colored 
beads, near age 12). 

Feurzeig et al. (1981) provide the most extensive set of cognitive 
outcomes expected from learning to program. They argue that 

the teaching of the set of concepts related to programming 
can be used to provide a natural foundation for the teach- 
ing of mathematics, and indeed for the notions and art of 
logical and rigorous thinking in general. 
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Learning to program is expected to bring about seven fundamental 
changes in thought: 

1. rigorous thinking, precise expression, recognized need to 
make assumptions explicit (since computers run specific algorithms); 

2* understanding of general concepts such as formal procedure, 
variable, function, and transformation (since these are used in pro- 
gramming); 

3. greater facility with the art of "heuristics," explicit ap- 
proaches to pix'oblems useful for solving problems in any domain, such 
as planning, findihg a related problem, solving the problem by de- 
composing it into parts, etc. (since "programming provides highly 
motivated models, for the principle heuristic concepts"); 

4. the general idea that "debugging" of errors is a "construc- 
tive and plannable activity" applicable tc any kind of problem solving 
(since it is so integral to the interactive natui*e of the task of getting 
programs to run as intended) ; 

5. the general idea that one can invent small procedures such 
as building blocks for gradually constructing solutions to large prob- 
lems (since programs composed of procedures are encouraged in 
programming); 

6. generally enhanced "self-consciousness and literacy about the 
process of solving problems" (due to the practice of discussing the 
process of problem solving in programming by means of the language 
of programn^ng concepts); 

7. enhanced recognition that for domains beyond programming 
there is rarely a dingle "best" way to do something, but rather 
different ways that have comparative costs and benefits with respect 
to^ specific goals (learning the distinction between "process" and 
"product," as in Werner, 1937). 

The question of whether or not programming promotes the develop- 
ment of higher cognitive skills raises two central issues in devel- 
opmental cognitive science. Firsts is it reasonable to expect transfer 
across knowledge domains? Even adult thinkers are notorious for 
their difficulty in spontaneously recoginizing connections between 
"problem isomorphs"— problems of identical logical structure but 
different surface form (Gick & Holyoak, 1980; Hayes & Simon, 1977; 
Simon & Hayes, 1976)— and in applying strategies for problem solution 
developed in one context to new problem forms. With problems of 
"near" transfer so acute, the possibility of spontaneous transfer must 
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be viewed cautiously. In later discussions, we provide a tentative 
developmental model for thinking about relations between different 
types of transfer beyond programming and different levels of pro- 
gramming skill. 

The second and related question is whether intellectual activity is 
guided by general domain-independent problem-solving skills or by a 
conjunction of idiosyncratic domain -dependent problem-solving skills 
(Goldstein & Papert, 1977| Newell, 1980; Simon, 1980). An extensive 
literature on metamemory development indicates that the tasks used to 
measure the functioning of abstract thinking are inextricably hnked to 
the specific problems used to assess metacognition (e.g.. Brown, 
1983a). As Ross and Howe (1981) note, "in most problem-solving 
tasks, it is impossible to apply the supposed context-free skills 
without initially having essentially domain-specific knowledge." Within 
domains, however, better performances by learners are commonly 
accompanied by reflection on the control of their own mental activities 
(Brown, Bransford & Ferrara, 1983). 

The Developmental Role of Contexts in Learning to Program 

For a developmentahst, there is a major problem pervading each of 
these characterizations of the effects on higher thinking skills ex- 
pected from learning to program. Programming serves as a "black 
box," an unanalyzcd activity whose effects are presumed to irradiate 
those who are exposed to it. But questions about the development of 
programming skills require a breakdown of the skills into component 
abilities, and studies of how specific aspects of programming skill are 
acquired. They reqidre especially serious consideration of the devel- 
opmental roles played by the contexts interpenetrating the black box: 
the programming environment, the instructional environment, and the 
relevant understanding and, performance of the learner. 

The question of the role of contexts in learning to program is complex 
because programming is not a unitary skill. Like reading, it is 
comprised of a large number of abilities that interrelate with the 
organization of the learner's knowledge base, memory and processing 
capacities, repertoire of comprehension strategies, and general prob- 
lem-solving abilities such as comprehension monitoring, inferencing, 
and hypothesis generation. This lesson has been etched in high rehef 
by intensive efforts to develop artificial intelligence systems that 
"understand" natural language text (e.g., Schank, 1982; Schank & 
Abelson, 1977). Skilled reading also requires wide experience with 
different genres (e.g., narrative, essays, poetry, debate) and with 
different goals of reading (e.g., reading for gist, content, style). 
Just as reading is often equated with skill in decoding, so learning to 
program in schools is often equated with learning the vocabulary and 
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syntax of a programming language. But skilled programming, like 
reading, is complex and contexts-dependent, so we must begin to 
unpack the contexts in which programming is carried out and learned. 

Environments in which children learn to read are usually overlooked 
because adequate environments (i.e., plenty of books, good lighting, 
picture dictionaries, good readers to help with hard words, vocabu-- 
lary cards, phonics charts) are taken for granted. By contrast, 
good programming environments are not generally available to schools. 
Determining how children develop programming skills will not be 
possible without due consideration of the programming environment in 
which learning and development takes place, and of how learning 
activities are organized. 

Programming Environment 

The distinction between a programming language and a programming 
environment is crucial. A programming language is a set of commands 
and rules that instruct the computer to perform specified operations. 
. The programming environment is the larger collection of software 
(operating systems and programming tools) and hardware (memory, 
disk storage, hard copy capability) available to the programmer. It 
can include an editor program to facilitate program writing , code 
revising, and copying useful lines of code from one program to an- 
other; debugging aids; elaborate trace routines ' for following the 
program's flow of control; automatic documenters; cross-reference 
utilities for keeping track of variables; and subroutine libraries. 

Good programming environments (e.g., those most extensively devel- 
oped, for working on large computers in Lisp and PL/ 1) make the 
coding aspect of programming far more efficient, allowing the pro- 
grammer to concentrate on higher level issues of program design , 
efficiency, and elegance. In contrast, the programming environments 
provided for today's school microcomputers are so impoverished (typi- 
cally consisting of only a crude editor and limited trace functions) 
that entering the code for a program and getting it to execute cor- 
rectly- is the central problem. 

Finally, despite vigorous arguments about the educational superiority 
of different px'ogramming languages, there are no data on whether 
different languages lead to significant differences in what children 
need to know prior to programming, or what cognitive benefits they 
derive from it. Although such differences among languages may 
exist, they do not affect our point since they car be radically manip- 
ulated by restructuring the programming environment. Attention is 
best directed to general issues about programming rather than to 
those that are programming language specific. 
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Instructiona l Environment 

While features of the programming environment are important for 
learning to program, how successfully a child will master programming 
also depends on the instructional environment and the way in which 
resources such as computer access time and file storage are allocated. 
Each of these points concerns the context of cognitive activities, 
which we know from cognitive science and developmental psychology 
to be critical to the level of performance achieved in cognitive tasks 
(for reviews, see Brown et al., 1983; LCHC, 1982). 

Deciding how to introduce programming and assist students in learn- 
ing to program is hampered today by the paucity of pedagogical 
theory. That current fact-learning approaches to programming in- 
struction are inadequate has become apparent from studies of the 
kinds of conceptual errors made by novice programmers instructed in 
that way. For example, novice adult programmers reveal deep misun- 
derstandings of programming concepts, and of how different lines of 
programming code relate to one another in program organization 
(Bonar & Sploway, 1982; Jeffries, 1982; Shell, 1980, 1981a; Soloway, 
Bonar & Ehrllch, 1983; Soloway, Ehrlich, Bonar ft Greenspan, 1982). 
As is to be expected from what they are taught, they know the 
vocabulary and syntax of their programming language. Their misun- 
derstandings are much deeper (Jeffries, 1982), such as assuming that 
all variables are global (when some may be specific to one proce- 
dure), and e^cpecting that observing one pass through a loop allows 
them to predict what will happen on all subsequent passes (although 
the outputs of programming statements which test for certain condi- 
tions may change what will happen during any specific loop). Re- 
search by Mayer (1976), MiUer (1974), and Sime, Arblaster and Green 
(1977) has revealed that adult novice programmers generally have a 
difficult time with the flow of control concepts expressed by condi- 
tionals (for a review of these findings, see duBoulay, O'Shea & Monk, 
1981). These conceptual difficulties, even among professional pro- 
grammers, have been lamented by such programming polymaths and 
visionaries as Minsky (1970) and Floyd (1979) as due to problems with 
how programming is taught. Too much focus is placed on low-level 
form such as grammar, semantic rxiles, and some preestablished 
algorithms for solving classes of problems, while the pragmatics of 
program design are left for students to discover for themselves. 
Interestingly, these complaints about writing programs are similar to 
those voiced about how writing in general is taught (e.g., Scarda- 
malia & Bereiter, 1983). 

We have observed that the conceptual problems of children learning to 
program are similar to those of adult novices. For example, in our 
research witlx 8- to 12-year-old Logo programmers (Kurland & Pea, 
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1983) , we find (through their think-aloud protocols and manual simu- 
lation of programs) that children frequently adopt a systematic but 
misguided conception of how control is passed between Logo proce- 
dures. Many children believe that placing the name of the executing 
procedure within that procedure causes execution to loop back 
through the procedure I when in fact control is passed to a copy of 
the executing procedure, this procedure is then executed and, when 
that process is complete, control is passed back to the procedure that 
last called it. Children adopted mental models of flow of control 
wnich worked for simple cases, such as programs consisting of only 
one procedure or tail recursive procedures, but which proved inade- 
quate when the programming goal required more complex programming 
constructions. 

In other developmental studies of Logo programming skills (Pea, 
1983), even the 25% of the children (8- and 9-year-olds; 11- and 

12- year-olds) who were extremely interested in learning programming 
wrote programs that reached but a moderate level of sophistication 
after iapproximately 50 hours of on-line programming experience 
during the year. Children's grasp of fundamental programming 
concepts, such as variables, tests, and recursion, and specific Logo 
primitive commands such as "REPEAT," was highly context-specific. 
For example, a child who had written a procedure using REPEAT 
which repeatedly printed her name on the screen did not recognize 
the applicability of REPEAT in a program to draw a square. Instead, 
the child redundantly wrote the same line-drawing procedure four 
times. We expect that carefully planned sequences of instruction' will 
be important to ensure thsit programming knowledge is not "rigid" 
-(Werner, 1957), or "welded" (Shif, 1969) to its context of first 
learning or predominant use. Such rigidity is a common finding for 
early developmental levels in diverse domains (Brown et al., 1983). 

In . the National Assessment of Educational Progres)^ survey of 2500 

13- year-olds and 2500 17-year-olds during the 1977-1978 school year 
(NAEP, 1980), even among the small percentage who claimed to be 
able to program, "performance on flowchart reading exercises and 
simple BASIC programs revealed very poor understanding of algorith- 
mic processes involving conditional branching" (cited by Anderson, 
1982, p. 14). 

Educators often assume that adult programmers are not beleaguered 
by conceptual problems in their programming, but we have seen that 
they are. Once we recognize that programming by "intellectually 
mature" adults is not characterized by error-free, routine perform- 
ances, we might better understand the difficulties encountered by 
children who devote only a small percentage of their school time to 
learning to program. 
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These findings lead us to two central questions about programming 
instruction, defined broadly to include the direct teaching provided 
by educators as well as thv^ individual advice, modelling, and use of 
metaphors with which they support instruction and learning, How 
much and what types of instruction should be offered? How much 
direct instruction is best for children to learn programming is a 
controversial quesjion^ (e.g., Howe, 1981; Papert, 1980). At one 
extreme, schools teach programming as they do any other subject, 
with fact sheets and tests; at the other, they provide minimal in- 
struction, encouraging children to explore possibilities, experiment, 
and create their own problems to solve. This second approach, 
popularized by Papert (1980), argues that little overt instruction is 
necessary if the programming language is sufficiently engaging and 
simple to use, while at the same time powerful enough for children to 
do projects they find meaningful. Though this discovery -learning 
perspective is not universally shared, even by Logo devotees (Howe, 
1981), it has had a pervasive influencie on the use of Logo by 
schools. 

What type of instruction should be off ered and , in the course of 
programming skill development , when splecific conceptis, methods, and 
advice should be introduced are also ciritical questions. Cognitive 
science studies implicate two central factors. One is the current 
mental model or system of knowledge that the student has available at 
the time of instruction. A second is the goal-relevance of the prob- 
lem-solving activity required by the student. On the first point, 
there are no careful studies of the success of different instructional 
acts as a function of a student's level of understanding for program- 
ming akin to those carried out by Siegler (1983) for such concepts as 
time, speed, and velocity. At a more getter al level, Mayer (1979, 
1981) has shown that a concrete conceptual model of a programming 
system aids college students in learning BASIC by acting as an 
advance organizer of the details of the language. With the conceptual 
model, learners were able to assimilate the details of the programming 
languiage to the model rather than needing to induce the model from 
the details. 

On the second point, we would ask how compatible the teacher's 
instructional goals are with the children's goals and purposes in 
learning programming. Recent developmental cognitive science and 
cross-cultural studies of cognition (e.g.. Brown, 1982; Laboratory of 
Comparative Human Cognition, 1983) have shown that assessing task 
performance within a goal structure familiar to the person is neces- 
sary for determining the highest developmental level of an individual's 
performance. The goals of the programming activity need to be 
contexted for the child in terms of other meaningful and goal-directed 
activities, connecting to everyday world affairs, to other aspects of 
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the curriculum, or to bpth. Papert (1980) has described this as 
"syntonic" learning. For example, in our studies, Logo classroom 
children found two contexts especially motivating: creating video- 
games and simulating conversations. The most intensive and advanc- 
ed programming efforts were in the service of goals such as these, 
thus reaffirming Dewey's (1900) point that new skills should serve as 
more adequate means for achieving desired ends. A similar emphasis 
underlies the successful use of electronic message and publishing 
systems in cl^issrooms (e.g.. Black, Levin, Mehan & Quinn, 1982; 
Laboratory of Comparative Human Cognition, 1982). Embedding 
computer programming activities of increasing cognitive complexity in 
children's goal structures may promote learning to program and 
support the transfer of what is learned in programming to problem- 
solving activities in other domains.' 

Our point throughout this section has been that programming is not 
taught by computers or programming languages but by teachers , with 
the aid of the supports of a programming environment. How effec- 
tively children of different ages and with different background knowl^ 
edge learn programmizig will be contingent on the capabilities of their 
teachers, the appropriateness of their learning activities to their 
current level of understanding in programming, and the features 
available in their programming environment. Studies to date have not 
incorporated these considerations recognized by a developmental 
cognitive science perspective as central. 

What is Skilled Programming ? 

How to define and assess the constellation of skills that comprise 
programming has long been a major problem for industry (Pea & 
Kurland, 1983b), and is becoming so for schools. We define program- 
ming as the set of activities involved in developing a reusable product 
consisting of a series of written instructions that make a computer 
accomplish some task. But in order to move from definition to in- 
struction, one must begin to unpack "programming skill," in contrast 
to the black-box approach to programming prevalent in schools. 
Promising moves in this direction have already been provided by 
careful analyses of what expert programmers do, and what types and 
organizations of knowledge they must draw on when they program. 
This research strategy, characteristic of cognitive science, has re- 
vealed significant general features of expert problem-solving skills for 
diverse domains, such as algebra (Lewis, 1981), chess (Chase & 
Simon, 1973), geometry (Anderson, Greeno, Kline 6 Neves, 1981), 
physics (Chi, Feltovich & Glaser, 1981} Larkin, McDermott, Simon & 
Simon, 1980), physical reasoning (deKleer & Brown, 1981), and 
writing (Bereiter & Scardamalia, 1982), and it is providing new 
insights into the components of programming skill. 
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Wh»t does a pyo^ramroer do ? Programming, for either novices or 
experts, involves a set of activities which constitutes phases of the 
problem-solving process (e.g., Newell & Simon, 1972; Polya, 1957). 
These act 'ities, which may be invoked at any time and recursively 
during the development of a program, are: (1) understanding the 
programming problem; (2) designing or planning a programming 
solution; (3) writing the programming code that iiriplements the plan; 
and (4) compi^ehension of the written program and program debug- 
ging. An extensive review of these cognitive subtasks of program- 
ming may be found in Pea and Kurland (1983b). 

What must an expert programmer know ? Findings on the knowledge 
schemfts, memory organizations, and debugging strategies which 
expert programmers possess are of particular interest. Recent 
studies of programmers characterize high-level programming skill as a 
giant assemblage of highly specific, low-level knowledge fragments 
(Atwood & Ramsey, 1978; Brooks, 1977). The design of functional 
"programmer's apprentices" such as Barstow's (1979) Knowledge Based 
Program Construction , and Rich and Shrobe's "Lisp programmer's 
apprentice" (Rich ft Shrobe, 1978; Shrobe, Waters & Sussman, 1979; 
Waters , 1982) , and the MENO Programming Tutor (Soloway , Rubin , 
Woolf, Bonar & Johnson, 1982) has involved compiling a "plan library" 
of the basic programming schemas, or recurrent functional chunks of 
programming code that programmers are alleged to use. Observations 
of programmers support these introspective analyses of chunks of 
programming knowledge. Eisenstadt/ Laubsch and Kahney (1981) 
found that most novice student programs were constructed from a 
small set of program schemas ^ and when Jeffries (1982) compared the 
debugging strategies of novice programmers and graduate computer 
science students, she found that experts saw whole blocks of code as 
instantiations Of well-known problems such as calculating change. 
Soloway and colleagues (Bonar, 1982; Ehrlich & Soloway, 1983; John- 
son, Draper & Soloway, 1983; Soloway & Ehrlich, 1982; Soloway, 
Ehrlich, Bonar & Greenspan, 1982; also see Kahney & Eisenstadt, 
1982) postulate a model in which programmers use recurrent plans as 
chunks in program composition, and identified such plans ir programs 
written by Pascal novices (e.g., the "counter variable plan"). But 
for developmental cognitive science, we will need studies of how 
students mentally construct such plan schemas from programming 
instruction, experience, and prior knowledge. 

A related aspect of programming skill is the set of rules that experts 
use to solve programming problems, but again wf lack genetic 
studies. In an analysis of a programmer's think-aloud work on 23 
different problems. Brooks (1977) demonstrated that approximately 104 
rules were necessary to generate the protocol behavior. Similarly, 
Green and Barstow (1978) note that over a hundred rules for mechan- 
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ically generating simple sorting and searching algorithms (e.g., 
Quicksort) are familiar to roost programmers. 

A third aspect of programming skill is the ability to build detailed 
mental models of what the computer will do when a program runs. An 
expert programmer can build dynamic mental representations , or 
"runnable mental models" (Collins & Centner, J981) and simulate 
computer operations in response to specific problem inputs. The 
complexities of such dynamic mental models are revealed \vhen skilled 
programmers gather evidehce for program bugs and simulate the 
program's actipns by hand (Jef fried. 1982). Not all program under- 
standing is mediated by hand simuiationj experts engage in global 
searches for program organizational structure, guided by adequate 
program documentation, a strategy akin to what expert readers do 
(Brown, 1983b} Brown & Smiley, 1978; Spiro, Bruce ft Brewer, 1980). 
How individuals develop such rich procedural understanding is cUr-| 
rently unknown. 

Expert programmers not only have available more knowledge schemas j 
strategies, and rules applicable to solving programming problems, butl! 
they perceive and remember larger chunks of infprthation than do 
novices. The classic Chase and Simon (1973) finding of short-term 
meniiory span advantages for chess experts over novices for meaning- 
ful chessboard configurations but not for random configurationfl has 
Ijeeh replicated for programming (Cus^, Sheppard, Millifa^ah, Borst & 
Love 1979} McKeithen, Reitman, Rueter & Hirtle, 1981; Nprcio 8r 
Kerst, in press; Sheppard, (Curtis, ijMiUiman A i^^^ 
man, 1977). For example, MbKeithiein et a. (19$ I^^^^ 
clustered keyword commands according to meani!hg (e.g., those func- 
tibning in loop statements)* whereas novices clustered according to a 
variety of surface ordinary language associations (such as ortho- 
graphic similarity and word length) , intermediates falling between the 
two. Similarly, Adelson (1981) found that recall clusters for experts 
were functionally or deeply based; those of novices were based on 
surfafce features of programming code. This is a major developmental 
transformation, but we do not understand how it occurs. DiPersio, 
Isbister and Shneiderman ' (1980) extended this research by demon- 
strating that performance by college students on a program memoriza- 
tion/reconstruction task provides a useful predictor of programming 
test performances. 

It is also a widely replicated finding that expert programmers debug 
programs iii different ways than do novices (Atwood & Ramsey, 1978; 
Gould, 1975; Gould & Drongowski, 1974; Youngs, 1974). Jeffries 
(1982) found that program debugging involves comprehension proc- 
esses analogous to those for reading ordinary language prose. Ex- 
perts read programs for flow of control (execution), rather than 
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line by line (as text). But how do programmers shift from surface to 
deep readings of programs as they develop debugging skills? 

In conclusion, we make one important observation, Expert program- 
me .'s know much more than the facts of programming language seman- 
tics and syntax. However, the rich knowledge schemas, strategies, 
rules, and memory Organizations that explert programmers reveal are 
only rarely directly taught. Many prdgrammittg students are at a 
disadvantage because of their l,ack of such understanding. This does 
not mean that they could not be taught, but to do so effectively will 
require considerable rethinking of the traditional computer science 
curriculum. These cognitive qualities appear instead to be a conse- 
quence of /an active constructive process of capturing the lessons of 
program writing experience for later use. 

Levels of Programming Skill Development 

To date, observations of levels of programming skill development (See 
Howe, 1980) have been extremely general and more rationally than 
empirically derived. Accounts of novice-expert differences in pro- 
grammliig ability among adults, coupled with observation of children 
learning to program, provid^ a starting point for developing a taxon- 
omy of levels of programmiiig proficiency. This taxonomy can guide 
our research by providing a developmental framework within which to 
assess a students' programming expertise and make predictions for 
types of transfer beyond programming as a function of a student's 
level of expertise. 

We believe that at least four distinct levels of programming ability can 
be identified that have implications for what types of skills might 
transfer as the result of their achievement. These levels represent 
pure types -and may not be characteristic of an individual, but cap- 
ture some of the complexities of what it means to develop prbgramming 
skills. We view these levels only as guides toward more adequate 
characterizations of the development of programming abilities. Fur- 
ther differentiation will inSvitably be required, in terms of the cog - 
nitive subtasks involved in the levels, and refined sublevels. 

Level I: Program user . A student typically learns to execute already 
written programs such as games, demonstrations, or computer-assisted 
ikistruction lessons before beginning instruction in how to program. 
What is learned here is important (i.e., what specific keys do, how to 
boot a disk, how to use screen menus), but does not reveal how the 
program works or that the program controls what happens on the 
screen. For many people, this level is sufficient for effective com- 
puter use (e.g., for word processing, game playing, electronic mail). 
But in order to be more in control of the computer and able to tailor 
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its capabilities to one's own goals» some type of programming is 
required. 

From this level we would expect relatively little transfer beyond 
computer use, but some transfer on computer literacy issues. For 
example i giv^n sufficiently wide exposure to different types of pro- 
grams* a student would be expected to know what computers are 
capable of doing, what they cannot do, and fundamental aspects of 
how they function in their everyday lives. As users, then, children 
might learn when computers are appropriate tools to apply to a prob- 
lem. 

Level II: Code generator . At this level the student knows the syntax 
and semantics of the more common commands in a language. He or 
she can read someone else's program and explain what each line 
accomplishes. The student can locate bugs that prevent commands 
from being executed (e*g., syntax errors), can load and save pro- 
gram files to and from an external storage device, and can write 
simple programs of the type he W she has seen previously. When 
programming, the student does very little preplanning and does not 
bother to document his or her programs. There is no effort to 
optimize the coding, use error traps, or make the program usable by 
others . A program created at this levfel might just print the stu- 
dentfs name repeatedly on the screen or draw the same shape again 
and again in different colors. The student operates at the level of 
the individual command and jdoes not use subroutines or procedures 
created as part of other programs. This level of understanding of 
the ^programming process is sufficient for creating short programs. 
But/to create more useful and flexible programs, the student needs to 
pro|ress at least to the next level. < 

At; level II, more specific types of computer literacy related transfer 
would be expected. Students should develop better skills for dealing 
with the more sophisticated software tools that are rapidly permeating 
the business world. Computer-naive users of office information 
systems (including calculators) have many problems (e.g., Mann, 
1^75; Nickerson, 1981b) and construct naive, error-ridden mental 
models of how they work (Mayer h Bayman, 1981; Newman 6 SprouU, 
1979; Young, 198p. Knowledge characteristic of this level may be 
required to attenuate these problems. Shell (1980, 1981a,b) provides 
compelling afguments that most systems require low-level programming 
if the user wishes to take advantage of system options, a basic 
competency he has designated as "procedural literacy." 

While potential computer literacy transfer from low-level programming 
exposure seems a reasonable expectation, what types of cognitive 
transfer should occur from this level of programming expertise is 
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disputable. Our observations of children programming at tli^s level 
suggest that some appreciation of the distinction between bug;s and 
^rrorst degrees of correctness t and the value of decomposing program 
goals into manageable subparts may develop and transfer to other 
domains, but that a student's attention is typically so riveted to 
Simply getting a program to work that any appreciation for more 
general cognitive strategies is lost. 

Level Illt Program generat or. At this level, the student has mas- 
tered the basic commands and is beginning to ihink in terms of 
higher level units. He or she knows that sequences, of commands 
accomplish program , goals (e.g., locate and verify a keyboard input, 
sort a list of names or numbers, or read data into a program from a 
separate text file). The student can read a program and explain its 
puzpose, what functions different parts of the program serve, and 
how the different parts are linked together. The student can ^locate 
bugs that cause the program to misfunction (e.g., a sort routine that 
fails to correctly place the last item in a list) or bugs that cause the 
program to crash as a result of unanticipated conditions or inputs 
(e.g., a division -by-zero error when the! program is instructed to 
find the mean of a null list). The student can load, save, and merge 
files and do simple calls to and from files inside the main program. 
The student may be writing fairly lengthy programs for personal use, 
but the programs tend not to be user-friendly « While the student 
sees the need for documentation, he or she does not plan programs 
around the need for careful documientation or clean' coding so that the 
program may be maintained by others. For this general level, one 
can expect to identify many subleyels of programming skill. 

Within this level of expertise, students should develop some appreci- 
ation for the process of designing a successful program. Such un- 
derstanding has potentially powerful Implications for their work in 
other domains, particularly if such relationships are explicitly drawn 
by the teacher for students, or exemplified in other domains. How- 
ever, it appears from our classroom observations and interviews- with 
teachers that for students to spontaneously, transfer computational 
concepts or language constructs used in one area of programming to 
other programming projects is a major accomplishment. Ideas about 
when to use variables or the value of planning, as in designing 
program "components so that they can be reused in the future, and 
following systematic conventions (such as beginning all graphics 
designs at their lower left comer) to make merging components into 
programs easier are all important accomplishments at this level that 
should not be taken for granted. 

Level IV t Software developer . Finally, at this level the student Is 
ready to write programs that are not only complex and take full 
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advantage of the capabilities of the computer, but are intended to be 
used by others. The student now has a full understanding of all the 
features of a language and how the language interacts with the host 
computer (e.g., how memory is allocated or how graphic buffers may 
be protected from being overwritten). When given programs to read, 
the student can scan the code and simulate mentally what the program 
is doing, see how the goals are achieved and how the programs could 
be better written or adapted for other purposes. Programs are now 
written with sophisticated error traps and built-in tests to aid in the 
debugging process and to ensure that the program is crash-proof. 
Beyon'i^ writing code accomplishing the program's objective, the stu* 
dent can optimiise coding to increase speed and minimize the memory 
required to run a program. To decrease the time needed to write 
programs, he or she draws heavily on software libraries and program- 
ming utilities. Finally, he or she often crafts a design for the pro- 
gram before generating the code, documents the program fully, and 
writes the program in a structured, modular fashion so that others 
can easily read and modify it. Major issues in software engineering 
at high sublevels within this level of expertise are discussed by 
Thayer, Pyster and Wood (1981). 

It is at this level of programming sophistication that we would expect 
to see the most extensive evidence for cognitive transfer. The 
student can distance him/herself sufficiently from the low-level coding 
aspects of program generation to reflect on the phases and processes 
of problem solving invplved. the issues of programming that concern 
the student at this level— elegance, optimalization, efficiency, veri- 
fication, provability, and style—begin to transcend low level concerns 
with program ekeeution, and may lead him or her to consider wider 
issues. The need at this level to be conscious of the range of in- 
tended users of programs forces the student to take the audience 
fully into account, a skill that has wide applicability in many other 
domains, such as writing. 

Implicit in these distinctions between levels of programmir g skill and 
their link to predictions about types of transfer is a theory of pro- 
gramming at odds with the naive technoromanticism prevalent in 
educational computing. While it is conceivable that even low levels of 
programming skill are sufficient to produce measurable cognitive 
transfer to nonprogramming domains, we contend that on the limited 
evidence available, this would be unlikely. Students who can barely 
decode or comprehend text are not expected to be proficient writers. 
Similarly, we doubt that students with a low-level understanding of 
programming and the skills that programming entails will write func- 
tional programs or gain insights into other domains on the basis of 
their limited programming skill. 
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Beyond asking what general cognitive characteristics may be prere- 
quisite to or substantively influence a child's learning to program, 
some ask what "developmental level" children must be "at" in order to 
learn from programming experiences. The concept of developmental 
level at the abstract theoretical planes of preoperational, concrete 
operational, and formal operational intellectual functioning has proved 
to be useful for instructional psychology in understanding children's 
ability to benefit from certain types of learning experiences (e.g., 
Inhelder, Sinclair & Bovet, 1974). But the very generality of these 
stage descriptions is not suitably applied to the development of spe- 
cific domains of knowledge such as programming skills. 

We have two reasons for not pursuing the development of program- 
tfling skills in terms of Piagetlan developmental levels. First, there is 
strong evidence that the development and display of the logical abili- 
ties defined by Piaget is importantly linked to content domain (Feld- 
man, 1980} Gardner, 1983; Piaget, 1972), to the eliciting context 
(Laboratory of Comparative Human Cognition, 1983), and to the, 
particular experiences of individuals (Price-Williams, Gordon 
Ramirez, 1969). Since it is not apparent why and how different 
materials affect the developmental level of children's performances 
within Piagetian experimental tasks, it is not feasible to predict the 
relationship between learning to program and performance on the 
Piagetian tasks. Our second objection Is that learning to program has 
neither been subjected to developmental analysis nor characterized in 
terms of its component skills, although such analyses are necessary 
for articulating measures that indicate the availability and develop- 
mental status of these skills for particular learners. 

While no research has been directly aimed at defining the cognitive 
prerequisites for learning to « program, at least six factors are fre- 
quently mentioned: ma1;h|ematical ability, memory capacity, analogical 
reasoning skills, condi^bnal reasoning skills, procedural thinking 
skills, and temporal rieasoning skills. These cognitive abilities, each 
of which has a complex ^ and well-researched developmental history, 
are presumed to influence learning to program and could be promising 
directions for future research. 

Mathematical ability . -Beyond general intelligence, programming skill 
is said to be linked to general mathematical ability. Computers were 
first developed to help solve difficult mathematical problems. Al- 
though many computer uses today are nonmathematical (e.g., database 
management, word processing), the notion persists that in order to 
program one roust be mathematically sophisticated. Media accounts of 
children using computers in schools have perpetuated the belief that 



programming is the province of math whizzes. Although we doubt 
that math and programming abilities are related once general intel- 
ligence is factored out, math ability cannot be ruled out as a pre- 
requisite to the mastery of certain levels of programming skill. 

Processing capacity . Programming is tiften a memory-intensive enter- 
prise requiring great concentration and the ability simultaneously to 
juggle the values of a number of parameters. Thus, individual 
differences in processing capacity are a likely candidate for in- 
fluencing who becomes a good programmer. Forward and backward 
span tasks, and more recently developed transformational span meas- 
ures (see Case & Kurland 1980; Case, Kurland & Goldberg, 1982), 
assess how much information one can coordinate at a given moment 
and appear to tadex processes basic to learning. Performance on 
such tasks has reliably correlated with general intelligence, Piagetian 
developmental level, and ability to learn and use problem-solving 
strategies (e.g.. Hunt, 1978). 

Analogical reasoninfs. A student may have background knowledge and 
capacities relevant to programming, yet neither connect Ihem to the 
programming domain nor transfer knowledge acquired in programming 
to other domains. This access of knowledge is fundamental to learn- 
ing and problem solving throughout life (e.g.. Brown, 1982). Trans- 
fers of knowledge and strategies, both "into" and "out of" learning to 
program, may depend on analogical thinking skills. Tasks designed 
to measure abilities for engaging in analogical thinking (e.g., Gick & 
Holyoak, 1980j Sternberg ft Rifkin, 1979) may predict level of pro- 
gramming development and transfer outcomes. Mayer (1975, 1981) 
argues that students learn programming by comparing the flow of 
control intrinsic to computational devices to the physico-mechanical 
models that they already possess. Also, duBoulay and O'Shea (1976, 
1978) have successfully used extensive analogical modelling to explain 
computer functioning to novice 12-year-old programming students. 

Conditional reasoning . Working with conditional statements is a major 
part of programming, since they guide the operation of loops, tests, 
input checking, and other programming functions. Thus, it is rea- 
sonable to predict that a student who has sufficient understanding of 
conditional logic—the various "if... then" control structures and the 
predicate logical connectives of negation, conjunction, and disjunc- 
tion—will be a more successful programmer than a student who has 
trouble monitoring the flow of control through conditional statements. 

Procedura l thinking . Several kinds of quasi-procedural, everyday 
thought may influence how easily a learner masters the flow of control 
procedural metaphor central to understanding programming,^ including 
giving and following complex instructions (as in building a model), 



writing or following recipes, and concocting or carrying out directions 
for travel. Presumably, learners more familiar with these linear 
procedures, analogous to the flow of control for computer operations 
expressed as instructions in a computer program, will more readily 
come to grips with the "procedural thinking" touted as a central facet 
of programming expertise (Papert, 1980; Shell, 1980). However, to 
date there has been little study of the development of procedural 
thinking. 

Temporal reasoning . The activity of temporal reasoning is related to 
procedural thinking, but with a distinct emphasis. Creating and 
comprehending programs requires an understanding of the temporal 
logic of sequential instructions: "it is the intellectual heart of 
learning how to program" (Galanter, 1983, p. 150). In teaching 
programming, Galanter says: 

The central theoretical concept that guided this effort was 
that classical forms of spatial-geometric-pictorial thinking 
must be augmented, and occasionally replaced, by temporal- 
imaginative-memorial logic. The child must learn to substi- 
tute an inner temporal eye for the outer spatial eye. 
(p. 163). 

Going somewhere in the program next , running one subroutine or 
procedure before another, ensuring one counter doeis not exceed a 
certain value until another operation is performed— these fundamental 
operations all require temporal understanding. Yet understanding 
temporal terms is a major developmental achievement, a challenge for 
children younger than seven or eight (e.g., Friedman, 1982; Piaget, 
1969). Futurity also presents complex conceptual problems for the 
planning activities involved in programming, such as imagining out- 
comes of the possible worlds generated by program design options 
(Atwood, Jeffries ft Poison, 1980), or the "symbolic executions" while 
writing programming code (Brooks, 1977). 

In sum, the cognitive constraints on developing programming skills 
are currently unknown.^ Although a developmental cognitive science 
perspective predicts that a student's attainable level of programming 
skill may be constrained by the cognitive abilities required in pro- 
gramming, there are no studies that relate level of programming skill 
to the abilities we have described. Children may have conceptual and 
representational difficulties in constructing dynamic mental models of 
ongoing events when the computer is executing program lines that 
constrain their level of programming skill. Also, systematic but 
naive mental models or intuitive epistemologies of computer procedural 
functioning may initially mislead children's understanding of program- 
ming, as with adult novices. Since learning to program is difficult 
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for many students, there is a serious need for research findings that 
will guide decisions about tailoring programming instruction according 
to a student's relevant knowledge prior to learning to program. 

Evidence for Goghitive Effects of Programming 

We now return to the claims for the broad cognitive impact of pro- 
gramming experience with greater awareness of the complexities of 
learning to program and issues of transfer. In sum, there is meager 
evidence for these cl&ims. 

Dramatic accounts have been offered of how some school-aged chil- 
dren's thinking about their own abilities to solve problems is trans- 
formed through learning to program (e.g., Papert et al. , 1979; Watt, 
1982j Weir, 1981; Weir & Watt, 1981), Important social interactional 
changes have been demonstrated in classrooms where children are 
learning Logo programming (Hawkins, Sheingold, Gearhart & Berger, 
1983) and r for some childrien, programming is an important and deeply 
personal intellectual activity. Similarly , many tieietcher reports focus 
on social and motivational rather than csognitive aspects of this expe- 
rience (Shejngold, Kane, Endreweit & Billings, 1981; Watt, 1982). It 
is not yet clear what the cognitive benefits of programming for such 
children may, be in terms of the transfer claims reviewed earlier. 

On the cognitive side, Ross and Howe (1981) have reviewed ten years 
of relevant research to evi.luate Feuirzeig et jJ.'s (1^69) four general 
claims on the cognitive impact of programming. The relevant research 
has been with Logo in nonrepresentative private schools. Below, we 
summarize Ross and Howe's review and integrate summaries of other 
studies relevant to these claims. In terms of pur account of levels of 
programming skill and the expected transfer outcomes, we must 
caution that, so far, studies (including our own) have an important 
hmitation. They have all looked at what we have designated as 
high-level or cognitive-transfer outcomes, expected to emerge only at 
the higher levels in our account of programming skill, whereas the 
levels of programming attained by the students in these studies were 
low because they only did six weeks to a year or so of programming. 
In other words, there has been a mismatch of "treatment" and trans- 
fer assessments because of a failure to appreciate the different kinds 
of transfer to investigate and their likely linkage to different levels 
of programming skill. For example, there are no studies that have 
assessed the low-level transfer or application of programming concepts 
such as "variable" in different types of programming within a lan- 
guage (e.g., graphics versus list processing in Logo), or from one 
programming language to another, or of comput«^r literacy outcomes. 
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First, tnere are no substantial studies to support the claim that 
programming promotes mathematical rigor. In a widely cited study by 
Howe, O'Shea and Plane (1979), researchers who were highly trained 
programmers spent tv*o years teaching Logo programming to eleven 
ll-year-^old boys of average or below average math ability. They 
studied Logo the first year and math with Logo the second year, each 
boy working for one hour per week in a programming classroom. 
Whien Logo students were compared with nonprogrammers (who on 
pretest had significantly better scores on the Basic Mathematics Test, 
but equivalent scores on the Math Attainment Test), they had improv- 
ed enough in basic math to eliminate the original performance gap 
with the control grou^, but fell significantly behind on the Math 
Attainment test. Such global math score differences do not support 
the rigor claim. The oft-cited finding is that the Logo group learned 
to argue sensibly about mathematical issues and explain mathematical 
difficulties clearly, but the finding is based only on differences in 
ratings of Logo and control students in teacher questionnaires (Howe 
et al. , 1979). The reliability of such ratings is questionable, since 
the math teachers should have been blind to which students learned 
Logo. 

Second, there are no reports demonstrating that programming aids 
children's mathematical exploration. Repor' by Dw^er (1975) for 
children learning BASIC, and Howe et al. lv: ), Lawler (1980), ahd 
Papert et al. (1979) for thos^ using Logo » 10 document children's 
goal^directed exploration of mathematical concepts such as variable on 
computers* Although math exploration and "mathland" play are likely 
to support math learning, studies have not shown any effects of 
math exploration during programming outside the programming envi- 
ronment, t/ ^ 

Third, although Feurzeig et al. (1969) suggest that the twelve 7- to 
9-year-old children to whom they taught Logo came to "acquire a 
meaningful understanding of concepts like variable, function and 
general procedure," they provide no evidence for the claim that 
programming helped the children to gain insight into these mathemat- 
ical concepts. 

Finally, we ask whether programming has been shown to provide a 
context and language that promotes problem solving beyond program- 
ming. Papert et al. (1979) conducted a Logo project with sixth 
graders for six weeks and reported, through anecdotal material, that 
children engage in extensive problem-solving and planning activities 
in learning programming » Whether or not such activities had cogni- 
tive effects beyond programming was not studied. However, Statz 
(1973) carried out a study to assess this claim. Logo programming 
was taught to sixteen 9- to 11-year-old children for a year. Statz 
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chose four problem-solving tasks with intuitive, ill-specified con- 
nections to programming activities as transfer outcome measures. The 
experimental group did better on two of these tasks (word puzzle and 
a permutation task), but no better on the Tower of Hanoi task or a 
horser'^ce problem thai Sfatzjhad designed. She interprets these 
findings as mixed support for the claim that learning Logo program- 
ming psromotes the development of more general problem solving skills. 

Soloway, Lochhead and Clement (1982) , in reaction to the finding that 
many college science students have difficulty translating simple alge- 
bra w^rd problems into equations (Clement, Lochhead t> Monk, 1979), 
found that more students solve such problems correctly when they are 
expressed as computer programs rather , than as algebraic equations. 
They attribute tiiis advantage to the procedural semantics of equa- 
tions in programs that many students lack in the algebraic task. 
This effect is much more restricted in scope than the increments in 
general problem solving skill predicted by the cognitive transfer 
claims. 

An important idea is that not only computer programs but one's own 
mental activities can lead to "buggy" performances and misunder- 
standings. Tools for diagnosing different types of bugs in such 
procedural skills as place-value arithmetic (Brown ft Burton, 1978; 
Brown ^ VanLehn, 1980; VanLehn, 1981) have restUted from extensive 
programming efforts to build "bug diagnostic systems" (Burton, 
1981). One may argue that the widespread recognition that system- 
atic bugs may beset perfojonances in other procedural skills* such as 
high school algebra (Carry, Lewis & Bernard, 1979; Matz, 1981) 
reflects a kind of transfer beyond programming. There is no evi- 
dence that programming students demonstrate such transfer. 

Planning in advance of problem solving , and evaluating and checking 
progress in terms of goals, are important aspects of a reflective 
attitude to one's ov^n mental activities (Pea, 1982). We have seen 
that the development of planning abilities is one major predicted 
cognitive benefit of learning to program. We therefore developed a 
transfer task for assessing children's planning (Pea & Hawkins, 
1983). We reasoned that a microgenetic method (Flavell ft Draguns, 
1957) allowing children to develop multiple plans was comparable to 
the rounds of revisions carried out during programming, and would 
allow for a detailed study of planning processes. Children planned 
aloud while formulating, over several attempts, their shortest-distance 
plan for doing a set of familiar classroom chores, using a pointer to 
indicate their routes. We gave the task twice, early and late in the 
school year, to eight children in eajch of two Logo classrooms (8- and 
9-yoar-olds; 11- and 12-year-olds), and to a control group of the 
same number of same-age children in the same school. There were 
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six microcomputers in each classroom » allowing substantial involvement 
with programming* 

As in related work on adult's pi' nning processes by Goldin and 
Hayes-Roth (1980; also Hayes-H* th , 1980 j Hayes-Roth & Hayes-Roth, 
1979), our product analyses centered on "plan goodness^ in terms of 
meticics of route efficiency, and our process analyses centered on the 
types and sequencing of planning decisions made (e« ^ . , higher level 
executive and me^planning decisions such as what strategic approach 
to take to the problem, versus lower level decisions of what route to 
take between two chore acts). Results indicated that the Logo pro- 
gramming experiences had no significant effects on planning perform- 
ances, on any of the plan efficiency or planning process measures 
(Pea & Kurland, 1983a). Replications of this work are currently 
under way with children in other schools. 

Conclusions 

As our society comes to grips with the information revolution, the 
ability to "deal effectively with computers becomes an increasingly 
important skilli. How well our children learn to use Computers today 
will significantly affect the society of tomorrow. Xhe competent 
application of higher cognitive skills such as planning and problem- 
solving heuristics in mental activities, bot^ with and without com-" 
puters, is a critical aim for education. As one contribution to these 
issues, we have argued for and documented throughout this paper the 
need for a new approach to addressing questions about the cognitive 
effects of computeir , programming. This approach, which we have 
characterized as developmental cognitive science, does not adopt the 
common perspective that computer programmers are all like adults, 
but is geared instead to the learning experiences and developmental 
transformations of the child or novice. The proposed research would 
be attentive to the playing out of those processes of learning and 
development in the instructional and programming environments in 
which the novice gains expertise. 

Can children become effective programmers? Does learning to pro- 
gram positively influence children's abilities to plan effectively, think 
procedurally, or view their flawed problem solutions as "fixable" 
rather than "wrong"? We have shown that answers to these questions 
depend on how "learning to program" is defined. We have reviewed 
cognitive science studies revealing that programming involves a com- 
plex set of skills, and have argued that the development of different 
levels of programming skill will be highly sensitive to contexts for 
learning, including processes of instruction, programming environ- 
ment, and the background knowledge the student brings to the task. 
We found few studies that could inform this new understanding, 
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although many promising research questions have been defined from 
this perspective. 

We have disinissed two prevailing myths about learning to program. 
The myth embodied in most programming instruction— that learning to 
program is "learning facts" of programming language semantics and 
syntax— Is untenable for two reasonst (l) It leads to major con- 
ceptual misunderstandings, even among adult programmers ; and 
(2) what Is taught belies what cognitive studies show good pro- 
grammers dp and know. * These studies have direct implications for 
new content and methods for programming instruction that are under 
development in several quarters. Studies of learning to program and 
of transfer outcomes are not yet available for cases where instruction 
has such npniraditionai emphases (e.g., on task analysis and prob- 
lem-solving methods that take advantage of what we know expert 
programmers do). We have also argued against the second myth— the 
spontaneov^-, transfer of higher cognitive skills from learning to pro- 
gram to other domains. Resistance In learning to spontaneous trans- 
fer and the predicted linkages of kinds of transfer beyond program- 
ming to the learner's level of programming skill were major points of 
these critical reviews. 

When thinking about children learning to program, what skill, levels 
can be expected? Reports of children learning to program (Howe, 
1981; Levin ft Kareeyv 1980j Papert et al., 1979; Pea et al., 1983), 
Including the learning disabled, the cerebral palsied, and the autistic 
(Watt ft Weir, 1981| Weir, 1981), suggest that most ehUdren can learn 
to write correct lines of code (level II in our account). This is no 
small achievement since writing grammatically correct lines of code is 
all that many college Students achieve In their first programming 
courses (Bonar ft Sbloway, 1982)* This level of programming skill 
may depend on the same abilities necessary for learning a first lan- 
guage. 



However, for programming skills that are an aid in problem solving, 
"grammatical" programming alone is Inadequate; the student must 
know how to organize code and plan schemas In order to accomplish 
specific goals. Development to these higher levels, where one be- 
comes facile with the pragmatics of programming, may require stra- 
tegic and planful approaches to problem solving that are traditionally 
considered metacognltlve, and more characteristic of adolescents 
(Brown et al., 1983) than primary school children. Further, the 
experience of the child In an elementary or junior high school pro- 
gram who spends from 30 to 50 hours per year In programming Is 
minuscule when compared with the 5,000 hours which Brooks (1980) 
estimates a programmer with only three years of experience has spent 
on programming. Since It is unreasonable to expect children to 
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become advanced programmers in the few years available to them in 
most school programming courses, our educational goals should be 
more realistic and achievable. As yetf we do not know what levels of 
programming eafpertise to expect but, in our experience, children who 
arb programlai^hg experts are uncommon. Thus, there are large gaps 
between what is me^t b^^^ to program in the computer science 

' Uterature, smd What lea^^ programming means to educators inter- 
ested in introducing childreil to this domain. These discrepancies 
should temper expectations for the spontaneous effects oii children's 
tMn]king m^ limited programming experiences in school, at 

least f^^^ programming Is taught (or not taught) today. Whether 
^sear^h on leaniixig ^^'t^^^^ learning experiences and 

ihli^ruiitibn powerful outcomes remains to be seen. In 

plaice of a naive technoromantici we have predicted thai the level 
of programming abilities a student masters will be a predictor of the 
kinds of concepts and skills he or she will transfer beyond program- 
ming . Although findings to date of transfer from learning to program 
haye not been encduf aging, these studies err in not linking level of 
prograimming 9kill to expected outcomes, and the critical studies of 
lowrley el transfjer expected from levels I and II reinain to be carried 
out. More importsaitly, with thinking skills as educational goals, it 

jnay be beisti to provide direct guidance t teaches or models trans- 
fer as a general asipect of highly deyeiopect thinking processes (Chip- 
mam, Siegel & Glaser, 1983; Smith Bruce, ^^81) * programming may 
provide tin excellent domain for suph purposes (Nickerson, 1982; 
Papert, 1980) . 

Thrpughout this paper, we have emphasized the heed for developmen- 
tal research in this areat empirical studies to refine our character- 
izations of levels of programming proficiency; extensive evaluations of 
the extent of transfer within and beyond programming in terms of 
different programming and instructional environments; and studies to 
help untangle the complex equation involving cognitive constraints, 
programming experience, and programming outcomes. We believe all 
these questions could be addressed by longitudinal studies of the 
learning and development process by which individual students become 
proficient (or not-so-p|roficient) programni^l^, and of the cognitive 
consequences of different levels of programming skill. Such studies 
would provide more rekvant information for guiding the processes of 
education than standard correlational studies. A focus on process 
and the types of interactions that students with different levels of 
skills have with programming and instructional environments is critical 
for understanding how development in programming skill is related to 
other knowledge. We are optimistic that others will join in work on 
these questions, for progress must be made toward meeting the 
educational needs of a new society increasingly empowered, by infor- 
mation technologies. / 




Footnotes 



The expectation that learning the concepts and language that 
underlie prograininlng will change the way a learner thinki of nonpro- 
griamming probleins recalls the strong formulation of the Sapir-Whorf 
hypothesis— that available linguistic labels constrain available 
thoughts. The strong form of this hypothesis has been extensively 
refuted (e. g . , Cromer, 1974) i only a weak version is consistent with 
evidence on laiiguage-thought relationships. Available labels in one's 
language may facilitate, but are neither necessary nor sufficient for, 
particular fpirms of thinking or cdnceptual distinctions. Categories of 
thought may provide the foundation for lin|(\iistic categories, not only 
the reverse. The same point applies to the language of programming. 

In (artificial) programming languages, just a^ in natural lan- 
guages, one taay distinguish among three majdr division^ of semiotics , 
or the scientific study of projperties of such signalling systems 
(Crystal, 1980). These three divisions, robted in the philosophical 
studies of Peirce, Carnap, and Morris, ares ^ 

Semantics , the study of the relations betweeii lingiiistic 
expressions aiid the objects in the wbr^d which they refer 
to or describe; syntactics , the study of the relation of 
these expressions to eath other; and pragmatics , the study 
of the dependence of the meaning of tl^ese eixpressiohs on 
their users (including the social situation in which they ^re 
used), ( op. cit l, p. 316) 

Studies of natural language pragmatics have focused on tne 

study of the language from thi point of view of the user, 
especially of the choices he makes, the constraints he 
encounters in using language in social interaction, and the 
effects his use of language has on the other participants in 
an act of communication, ( op. cit ., p. 278) 

Though there are important disanalogies to natural language, a prag- 
matics of programming languages concerns at least the study of 
programming language (s) from the point of view of the user, espe- 
cially of the (design) choices he or she makes in Jhe organization of 
lines of programming code within programs (or software systems) ; the 
constraints he or she encounters (such as the requirements of a 
debuggable program that is well-documented for future comprehension 
and modification) in using programming language in social contexts; 
and the effects his or her use of the programming langu?i^e has on 
the other participants (such as the computer, as ideal interpreter, or 
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other humans act oi cdmihunication involving the use of the 

^'p!irograinrain,g", language ■ 

J The concept of ''Jfow pf CQntrol"^^^^ r^ the sequence of 

operations that ai computer program specifies. The need for the term 
erterges^ lliiear. Itt linear control* lines of 

pir^gramming insii^cttehs wou^^^ executed in strict linear orcier-- 
fcrsit. Second, third, and $b oji* But in virtuaily all programining 
la!*i»iai^s» ;yjEu^ !lCo|itrol structures"^. used; to IeOIow nonlineai^ 
control. F6r example, one^ may "GOTO" other than the next line in 
the program in BA$IC , in which case fldw of control passes to the 
line of programming code referred to in the GOTO statement. Be- 
t^use a. program's flow of control may be complex , programmers often 
utilize programming flowcharts, either to serve as a high-level plan 
for creating their program, or to document the flow of control in 
their program. 

4 .: ■ ■ ■ , " ;:, ,■ ■ ' " . ... ;■ : 

What is "quasi-procedural" rather than "procedural" about 
giving and following task instructions, dhrectiohs, and recipes is 
that, unlike procedural instructions in a computer program, there is 
often ambiguity in the everyday examples, such that the instructions, 
directions, and recipes are not always unequivocal iii meaning i' They 
are also not constrained by strict sequentiality . One may often 
choose to bypass steps in a recipe or set of instructions, or to 
reorder the steps. Neither option is available in the strict procedur- 
ality of programmed instructions. Yet similarities between the every- 
day cases and programming instructions are compelling enough to 
make their designation as quasi-procedural understatidable. 
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